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Checking Checked Check Boxes 


By Joe Kroeger 

Oof ! In issue #571 posed a brief question in the 
Quick Tips section. It went something like this: 

Perhaps one of our many clever subscribers 
can suggest an answer to this question: Is it 
possible to calculate the number of check 
boxes that are checked in a field? Figure 1 
shows a field formatted with check-boxes. 

What is needed is another field that calculates 
for each record how many of the check¬ 
boxes are checked. 

I knew we had a bunch of smart subscribers but I 
expected to receive just a few replies since readers are 
normally quite busy. Somehow, however, this ques¬ 
tion stimulated a bunch of replies — far more than 
for any other questions raised in the newsletter over 
the years. There have been faxes, phone calls, letters, 
and e-mail. Each new reply seems to add another 
factor to consider or another detail to take care of or 
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Figure 1 


another interesting approach to a solution. At press 
time a few are still arriving. Many, many thanks to all 
of you for taking the time to communicate, for help¬ 
ing with the answers, and for sending in such really 
interesting stuff. 

Often check boxes are used simply as an aid to 
entry of data into a field. But for some uses it would 
be nice to know how many boxes are checked in 
addition to what is checked. A questionnaire with 
“select all that apply” instructions might like to have 
such a count. Consider a field in a Claris registered- 
owner database that lists all of the Claris products: 

continued on page 3 
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What is a Check-Box field and how is it used? 

A FileMaker Value List is a pre-defined list of data associated with a field as an option. It 
can be used to enter an item from the list into a field by selection from the list. In FileMaker 
Pro a variety of presentations of the list information are possible. 

Creating and using any value list is a two-step process: (a) Select a field to be used with a 
list, assign the value list option to the field, and enter the desired list, (b) In each layout where 
the field is used, format it for the desired type of display. 

Nested within the field Definition dialog is the Options dialog box. It includes an option 
to “Use a pre-defined value list:” When this option is active, a value fist can be entered that 
then lives in the field. 

Cut, Copy, Paste, and Select All operations work fine while creating and editing a value 
list, as long as keyboard shortcuts are used for the commands (The Edit menu is not available 
within the dialog). Items can also be pasted into the list from the clipboard. The four key¬ 
board arrows are available to move the cursor around the list. 

Once a field has been defined to include a value list and has been placed on a layout, it 
can be formatted in any of four ways, or not at all. In Layout mode, click once on the field 
and select the field Format command from the Format menu. If you do not check the option 
labeled “Use field’s value list to display field as:” the field will remain formatted as a plain, 
non-fist field. When the option is checked, four display sub-options are available: radio but¬ 
tons, check boxes, pop-up menu, pop-up fist. Each of these has a different set of characteris¬ 
tics. Radio buttons and check boxes have one button for each item in the value fist. Radio 
buttons are normally used in such a way that only one is active at a time— when another is 
selected, an already-active button is automatically turned off. 

Check Boxes 

Check box formatting displays the value fist and associates a square check box with each 
fist item. Check boxes permit any number of the items in the value fist to be selected at the 
same time, or for no selections at all to be active. A field formatted with check boxes can be 
tabbed into (new feature). FileMaker underlines the field name label of formatted fields but 
the label style can be changed to anything desired. 

Items on the check box fist are selected or de-selected by clicking on the desired check 
box or on its associated text. (Arrow keys can also be used to move through the list and the 
return key will toggle the highlighted check box.) Check boxes show up in a Find request the 
same way as in Browse and can be used in the specification of the Find. 

One nice feature of check boxes is that the only data entered are items from the fist— 
there is no easy way to type in information not from the fist. Thus wording and spelling are 
consistent. Flowever, if you want to be able to enter items into the field that are not on the fist, 
use the “Other” option for the fist. It allows manual entry of an item not on the fist. When 
multiple boxes are checked in one record, all the selected entries are entered in the field. 

For more details about check boxes and other value fist options, see the article on Value 
Lists from issue #46. But note that some of the information there is now out of date with the 
advent of changes in FileMaker Pro 2. 
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FileMaker, MacWrite, ClarisWorks, Resolve, 
MacDraw and so forth. It then makes sense to 
add up the number of products for which each 
owner is registered. Many other examples are 
possible. 

Check Box Characteristics 

In a check box field (see sidebar on page 2), 
FileMaker puts any selected items from the 
value list into the field field. Indeed, the basic 
purpose of Value Lists, no matter how they are 
formatted, is to aid data entry. (In addition, 
Value Lists are used for setting up custom sort¬ 
ing.) If no boxes are checked, nothing is en¬ 
tered in the field and View Index will reveal it 
to be empty. If one box is checked, the value 
associated with the box appears in the field 
(not obvious except with View Index). If more 
than one box is checked in the same check box 
field, FileMaker enters all of the checked val¬ 
ues. A return character follows each entry ex¬ 
cept the last one. For one entry the first item is 
also the last one and is not followed by a return. 
If return characters could be seen in the com¬ 
panion field, the entries would look like the 
example in Figure 3 (on the next page). The 


structure of the contents of check box fields is 
important for the project at hand. 

Not only are all the checked boxes reflected 
in the field, but the entries appear in the se¬ 
quence that the buttons were selected (Figures 2 
and 3). When a check box is toggled off, the 
corresponding entry is removed from the field 
no matter where it may be in a sequence. If 
there is other information in the field — perhaps 
from manual entry or as historical or imported 
data — the old data is retained in addition to 
any information entered using the check boxes. 
See Figure 4 on the next page. 

Fixed-Length Lists 

How might we calculate how many check 
boxes are checked in a field? As opposed to 
which boxes are checked. An approach that 
many readers have mentioned is to simply 
calculate the length of the field and use that 
information (in various ways) to decode the 
number of boxes checked. Especially for the 
simple example in the original question (Figure 
1), length works well and represents a good 
starting point for devising specific solutions. 
(Looking at length had not occurred to me; 


Seeing the Action 

An easy way to investigate just what is happening in a check box field is to create a layout with a field format¬ 
ted with check boxes and then next to it the same field formatted as a plain field. (It also works to make the sec¬ 
ond field a calculation that simply is equal to the first. But why add unecessary complication?) Then as various 
combinations are checked the results are reflected directly in the plain field as soon as the check field is exited (I 
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usually hit the enter key). 

The plain field also allows a Replace opera¬ 
tion for clearing away old data in the field or for 
preloading value(s) in a set of records. 

Note that when a list item contains more than 
one word, View Index splits the words, as usual, 
so that it may seem like there are return charac¬ 
ters. The plain field presentation provides an 
exact indication of the field contents. See Figure 2 
for an example. Both fields are the same field, but 
with different formatting. 
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had I thought of it, I might not have been moti¬ 
vated to ask the question at all.) 

Let’s say we have a field called Fruitl with a 
value list of five items: A, B, C, D, and E. See 
Figure 5. To figure out the number of active 
boxes in Fruitl we can add two new calcula¬ 
tion fields that look like this: 

FruitLength = {numeric result} 

If (Fruitl = 0, Length (Fruitl)) 



ItemsCheckedl = {numeric result} 

If (FruitLength = 0,0, If (FruitLength = 1,1, 

If (FruitLength = 3,2, If (FruitLength = 5,3, 

If (FruitLength = 7,4, 

If (FruitLength = 9,5,999)))))) 

Any Length calculation returns a blank 
instead of a zero when there is nothing in the 
field, so I’ve detected the empty condition 
separately — thus the FruitLength field reflects 
any condition the field might be in. Items¬ 
Checkedl is designed for the case of five check 
boxes that have one-character items in the list 
(like Figure 5). The series of nested If functions 
in ItemsCheckedl tests the length of each 
combination of boxes that might be checked. 
The specific values used in each If are derived 
from the lengths of entries in the associated 
value list plus taking into account return char¬ 
acters. Figure 6 shows these two calculations at 
work. When a length other than one of the pre¬ 
supposed combinations is present, the value 
999 is the result, indicating an error. 

If all the list items are two characters long 
instead of one, the calculation would change to: 

ltemsChecked2 = {numeric result} 

If (FruitLength = 0,0, If (FruitLength = 2,1, 

If (FruitLength = 5,2, If (FruitLength = 8,3, 

If (FruitLength = 11,4, 

If (FruitLength = 14,5,999)))))) 

(Note that the FruitLength calculation can 
be combined with the CheckNumber equa¬ 
tions so that only one formula is needed. But I 



find it easier to grasp what is going on when 
they are separate. Using multiple calculations is 
a good technique when the equation would 

I otherwise be complicated — it is easier to see 

intermediate results and therefore easier to 
debug. Once everything is working it will some¬ 
times, though not always, be useful to collapse 
multiple calculations into one.) 

There were a few attempts by readers to 
make a generic calculation for lists with entries 
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that were all the same number of characters, 
but I could not get them to work quite right. 
Alternative shorter expressions are possible, 
especially for a longer list of items, that accom¬ 
plish almost the same thing as ItemsCheckedl 
and do not need FruitLength. Instead of trans¬ 
lating the given length into a number of check 
boxes using nested If functions, there are also 
ways to calculate the number directly. 

ltemsChecked3 = ((Length (Fruitl) -1) / 2) +1 

or 

ltemsChecked4 = ((Length (Fruitl) +1) / 2) 

or 

ltemsChecked5 = 

Length (Fruitl) - ((Length (Fruitl) -1) / 2) 

None of these three provides zero when 


nothing is checked. They can be modified, of 
course; do so by testing for an empty field and 
supplying a zero if needed, in a manner some¬ 
what like FruitLength, used earlier. 

Another alternative approach: 

ltemsChecked6 = 

Round ((Length (Fruitl)) / 2,0) 

This equation returns a blank when no 
boxes are checked. It can also be used easily 
with longer list items if they are all the same 
length. This approach can be generalized to 
Round (Length (A) / (B + 1), 0) where A = 
Checkbox field and B = Length of each entry in 
the Value List. “0” (zero) is the parameter that 
specifies rounding to the nearest first digit. 

Another approach based on length uses the 
Integer function: 

ltemsChecked7 = Int ((FruitLength / 2) + 0.5) 

This version does work properly when there are 
no entries. 

You may find some interesting ideas in one 
of the ItemsChecked4-7 to play with. Adapt 
them to your particular situation. 

Variable Length Items 

What if the entries are different lengths? 
Let's say we have a field called Fruit2 with a 
value list of five items: Orange, Banana, Pear, 
Cumquat, Strawberry. See Figure 7. This is a 
more general case than what has been consid¬ 
ered so far. Calculations like ItemsCheckedl 



break down when confronted with vari¬ 
able-length items on the value list: a com¬ 
bination of items from the list might be the 
same length as another item. A calculation 
that relies on counting lengths to decide 
how many entries are checked would then 
get fooled. 

But notice that any approach that relies 
on all entries being the same length can 
work if the different-length entries are 
converted to same-length entries by pad- 
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ding the shorter ones with spaces. This neat 
suggestion from a couple of readers can 
solve several problems. But remember to 
take the extra spaces into account in other 
areas that may use the field — Finding op¬ 
erations, for example. Figure 8 shows how 
Figure 7 would look if the entries were 
doctored with spaces and if spaces looked 
like asterisks. For Figure 8 the calculation 
for ItemsChecked6a is the same as for 
ItemsChecked6 except that the item length 
has been changed to 10: 


Count CheckboH Figs 
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ltemsChecked6a = {numeric result} 

Round ((Length (Fruitl)) / 10,0) 

An alternative is to count characters for 
each combination and make a variation of 
ItemsCheckedl for items that are all ten char¬ 
acters long: 

ItemsCheckedl a = {numeric result} 

If (FruitLength = 0,0, If (FruitLength = 10,1, 

If (FruitLength = 21,2, If (FruitLength = 32,3, 

If (FruitLength = 43,4, 

If (FruitLength = 54,5,999)))))) 

Faking It 

There is another way to simplify things by 
keeping all the list values the same length. It 
can be used when having the actual values in 
the field is not important, only how many have 
been checked. Make the value list with simple 
generic values like 1, 2, 3 or A, B, C (like 
Figure 5). Then, for the sake of the user 
entering data, put alternative names for the 
items list on the layout next to the check 
boxes. See Figure 9. This scheme makes it 
easy to have any kind or length of items 
desired while keeping the actual value list, 
and therefore the needed calculation, quite 
simple. 

Note that, if necessary for other rea¬ 
sons, there is a correspondence between 
the layout labels and the values actually 


entered in the field. That is, any “C” values can 
be interpreted as whatever is designated, in the 
case of Figure 9 as “Pear”. 

As a further simplification, it might be 
assumed that in some cases it would not even 
be necessary to put different values in the fist. 
How about just A, A, A or *, *, • or spaces or, 
even more simply, only return characters. If 
just 1 's were in the list, how easy it would be to 
simply add the one’s to count the entries! But 
none of these works: a check-box value fist 
needs to (a) contain something, and (b) con¬ 
tain only mutually-exclusive values. 

Looking at Returns 

We can gather from the characteristics of 
checkbox fields that another approach is possi- 
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ble: locate the returns that FileMaker inserts in 
the checked field and use that information to 
detect how many entries there are. While there 
are several potential ways to do so, a straight¬ 
forward approach was submitted that goes like 
this: Given the Fruit2 field, create a series of 
calculations that decode the positions of return 
characters in that field: 

FirstReturn = Position (Fruit2, "11", 0) 

SecondReturn = 

Position (Fruit2, "H", FirstReturn + 1) 
ThirdReturn = 

Position (Fruit2, "IT, SecondReturn + 1) 
FourthReturn = 

Position (Fruit2, "H", Third Return + 1) 

Fifth Return = 

Position (Fruit2, "H", FourthReturn + 1) 


value list. The tradeoff is that the lengths of 
individual entries are no longer relevant — as 
long as the return characters are detectable, 
ItemsChecked8 should work well. It also works 
nicely when list items are multiple words. 

Shift the Premise 

Of course, we could just change the ground 
rules altogether and make the input fields more 
complicated in return for simpler calculations. 
Instead of one field with a value list of five items, 
how about five fields that each have a value list 
of one item? 

OrangeFruit Text field, value list: Orange 
BananaFruit Text field, value list: Banana 
PearFruit Text field, value list: Pear 

CumquatFruit Text field, value list: Cumquat 
StrawberryFruit 

Text field, value list: Strawberry 


... and so forth if necessary. 

We need to know not the actual position of 
the returns (H), but just whether there is one. 
Thus once the positions of the returns have 
been calculated, we simply need to figure out 
how many there are. We use the same Fruit- 
Length equation as the one on page 4 and we 
then calculate a new ItemsChecked: 

ltemsChecked8 = {numeric result} 

If (FruitLength > 0, If (FirstReturn = 0,1, 

If (SecondReturn = 0,2, If (ThirdReturn = 0,3, 

If (FourthReturn = 0,4, 

If (FifthReturn = 0,5,))))), 0) 

In ItemsChecked8 we are looking for the 
first missing return in the series. If the length is 
non-zero and there is no return, we know that 
one box has been checked. If instead there is no 
second return, we know that two boxes have 
been checked. If the length is zero we know 
that no boxes have been checked. 

When looking for return characters there 
are more calculation fields to worry about, 
especially with a large number of items in the 


Then arrange the five fields on the layout 
for data-entry convenience or to imitate a sin¬ 
gle field with five check boxes. This is a quite 
interesting approach if the data is not needed 
in one field. Determining the number of items 
checked is straightforward: 

ltemsChecked9 = {numeric result} 

If (OrangeFruit > 0,1,0) + 

If (BananaFruit > 0,1,0) + 

If (PearFruit > 0,1,0) + 
if (CumquatFruit > 0,1,0) + 

If (StrawberryFruit> 0,1,0) 

And if this scheme is useful, yet you want 
to collect the checked information into one 
field (say for Finding or Sorting convenience), 
it is easy enough: 

AllFruit = {text result} 

OrangeFruit &"" & BanannaFruit &"" 

& PearFruit &"" & CumquatFruit &"" 

& StrawberryFruit 
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Total Pears = Total IsPear 


{summary} 


Looking at the Contents 

A different, content-oriented approach 
appeared in the Coulombre/Price bookFile- 
MakerPro 2.0 For Macintosh and was pointed 
out by a couple of readers. (This nice book, 
published by Addison-Wesley, is subtitled “A 
Practical Handbook for Designing Sophisticat¬ 
ed Databases". It is one of the few good books 
available about FileMaker.) The technique they 
present detects the presence of specific entries 
from the list using the Position function. You 
can try something like it by building a calcula¬ 
tion for each list item: 

IsOrange = {numeric result} 

If (Position (Fruit2, "Orange", 0) > 0,1,0) 

IsBanana = {numeric result} 

If (Position (Fruit2, "Banana", 0) > 0,1,0) 


A summary field for each list item allows a 
summary report of all fruits checked. 

Hello! 

It is always nice to bump into a new File¬ 
Maker surprise, and they still happen frequent¬ 
ly enough to keep things interesting. 
Nonetheless, after all this work and debugging 
and hard thinking, I was caught off guard by a 
simple and off-beat solution. It came from a 
clever subscriber and makes non-standard use 
of a FileMaker function. Assume that Fruit3 is 
a text field with a value list of numbers. Watch 
this: 

ItemsCheckedl 1 = {numeric result} 

Length (Sum (Fruit3)) 


IsPear = {numeric result} 

If (Position (Fruit2, "Pear", 0) > 0,1,0) 

IsCumquat = {numeric result} 

If (Position (Fruit2, "Cumquat”, 0) > 0,1,0) 

IsStrawberry = {numeric result} 

If (Position (Fruit2, "Strawberry", 0) > 0,1,0) 

Then a simple addition of the five fields 
indicates how many items have been checked: 

ItemsCheckedl0 = {numeric result} 

IsOrange + Is Banana + IsPear + IsCumquat + 
IsStrawberry 

Depending on a the circumstances, it may 
also be necessary to detect the presence of oth¬ 
er data in the field and flag it as an error. 

Alert = {text result} 

If (ItemsCheckedl 0 = 0 and Length (Fruit2) > 0, 
"ALERT!","") 

This approach makes it easy to go one step 
further since the detecting calculations are 
examining the actual content of the field. A 
supplementary summary field can add up all 
the, say, Pears in a found set. 


Should this work? It does! Recall that Sum 
is a function that usually applies only to repeat¬ 
ing fields and is normally used for the addition 
of a column of repeating field numbers. In 
ItemsCheckedl 1, however, Sum is being ap¬ 
plied to multiple entries created in a non-re¬ 
peating field that has a checkbox format. The 
result, for me, was quite unexpected: concate¬ 
nation of the entered values. The return char¬ 
acters are gone. This makes it easy to know 
how many items have been checked by simply 
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Uniqueness Through Binary Values 

While only indirectly related to checking check 
boxes, there is an interesting arithmetical characteris¬ 
tic that might help solve a problem. Assume that it can 
be arranged to have either actual values or value-lengths 
of, for example, 1, 2,4, 8, and 16. Assume further that 
a numeric total of the values (or the lengths) selected 
from the list can be calculated. The result will a unique 
number that uniquely indicates the components that 
make up the total value. 

If the total is 13, for example, the values 1,4, and 8 
are the items picked from the list and no other combi¬ 
nation will yield 13. Notice that 13 not only indicates 
how many values went into the total, but which values. 
This works for any combination of inital values as long 
as they are binarily related: each double the previous. 

Let’s say the list contains 512, 1024, 2048, 4096, 
8192, 16384. And let’s say the total is 12800. Then the 
only components possible are 512 and 4096 and 8192. 
No other number or combination of numbers from 
the given list is possible. 


calculating the length of the result of the Sum. 
Elegant. See Figure 10. (I included a calculation 
that is just Sum (Fruit3) so you can see the 
transformation with your own eyes.) 

But this version works only as long as the 
value list contains single-digit values. 

If you need a list of more than nine values, 
make sure all the entries are unique two-digit 
numbers (which makes room for a list of 90 
values) and use a slightly different version of 
ItemsCheckedll: 

ItemsCheckedl 2 = {numeric result} 

(Length (Sum (Types))) / 2 

See Figure 11. This can be extended even 
further, of course. You might also want to 
experiment with how Sum works for text val¬ 
ues and/or numeric fields. 

I really enjoy this kind of delving into File¬ 
Maker details and variations and gimmicks. 
Thanks for all the submitted ideas.* I’m sure 
there are even more approaches that have not 
been covered here. If you run across other ways 
to deal with this subject, please let me know. 

One lesson from this, that we seem to re¬ 
learn continuously, is that FileMaker has un¬ 
ending potential — that there are lots of ways to 
conquer problems — that, indeed, “If it can’t be 
done with FileMaker, it’s just not worth doing.” 
Creativity in FileMaker means (a) allowing your¬ 
self to believe that solutions are possible, (b) 
giving yourself permission to see a problem 
from an entrely different angle. Of course, it 
does not hurt that you are subscribing to this 
newsletter as well. 


* Some contributions arrived without attribu¬ 
tion so I’m not always sure who sent what. 
Cover letters tend to get separated from exam¬ 
ple files. Please be sure to put your name inside 
of any FileMaker or word processor files you 
send along. Thanks. 
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Creating Even Multiple Columns 


By Dave Burnett 

One of my clients had an interesting project: 
design a FileMaker database that would print 
price tags for audio-visual equipment. This 
seemed easy enough at first glance — a field for 
the name of the product, a field for the price, 
and a few fields for product description. How¬ 
ever, the project became more complex as I 
worked to flesh out the desired feature set. 

Price tags do more these days than just list 
the price of the product — in describing items 
they become marketing devices with a listing of 
features. As a marketing tool, they need to look 
good as well. Therefore, it was very important 
that this database, now called AutoSign™, 
contain tools that would make it easy for the 
user to control the look and feel of each of the 
signs and tags. This article describes the tools I 
created for formatting of sentences that de¬ 
scribe the product features. Each short phrase 
is referred to in the industry as a “bullet” and 
I’ll use that nomenclature in this article. 

The Project 

The requirement was for up to ten fields 
containing text that would describe each piece 
of A/V gear. In some price tag layouts there 
would not be room for ten bullets and I wanted 
the user to be able to select which of the ten 
would be used. Additionally, giving the user 
positive control over which bullets would be 



used creates a new feature: some sentences can 
be designed for special occasions like sales (e.g. 
“New Low Price”). I decided that a good user 
interface for controlling use of the bullet text 
would be to create a checkbox for each field. 

See Figure 1. The default is that all lines con¬ 
taining text are used — if the checkbox is select¬ 
ed, the corresponding bullet field would not be 
used on the price tag. 

Unexpected Difficulties 

The client and I iterated through several 
versions of AutoSign. Soon the client’s art 
department faxed me the final set of label de¬ 
signs that were to be included with the product. 
The plan had been that the graphic designers 
would create some generic labels in Quark 
XPress and that I would then replicate their 
ideas within FileMaker. However, with just a 
glance at the fax I knew that I would have a 
problem reproducing their complex designs. 
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Figure 2 Figure 1 















Figure 3 


The art department had never created a File¬ 
Maker database and since no one had told 
them that FileMaker is not as graphically versa¬ 
tile as Quark, they went wild and designed very 
visually-sophisticated price tags. 

While I was able to recreate much of their 
design look and feel with clever use of both 
typography and field positioning, one idea was 
apparently undoable in FileMaker. Two of the 
proposed layouts had the product bullets in 
two columns within the layout. See Figure 2. 

Normally this would be easy: bullet fields 
one, three, five, seven, and nine would be 
arranged in the first column and bullet fields 
two, four, six, eight, and ten would be similarly 
arranged in the second column. The problem 
arose in that we were allowing the user to tell 
FileMaker not to use certain bullets. So, using 
this technique, if someone turned off a bullet, 
then one column could have more bullets than 
the other. See Figure 3. 

After experimenting with some simple 
calculation fields and trying different sliding 
options, I was getting ready to tell the client 
that it couldn’t be done in FileMaker. I paused 
one last time to approach the problem afresh; I 
knew from using FileMaker for more than five 
years that it can be made to do most anything. I 
went back to the drawing board, scratched my 
head for awhile, and came up with a solution. 

Visualizing an Approach 

I looked at this from the outside in — going 
from what the output needed to look like to 
what would be required to make it work. Func¬ 


tionally speaking, I needed “smart columns”: 
columns that understood that bullets could be 
turned on and off and that would automatically 
display the correct set of bullets. If you num¬ 
bered each bullet that was to be used, it was 
clear that the left column would always display 
the odd numbered bullets and the right would 
display the even numbered bullets. So in addi¬ 
tion to “smart columns”, I needed “smart bul¬ 
lets”: bullets that would report either that they 
should not be used or their number in the list 
of active bullets. 

Implementing the Design 

I started out with ten fields (BulletText- 
One, BulletTextTwo, BulletTextThree,...) 
for storing the bullets plus ten check-box fields 
(CheckOne, CheckTwo, CheckThree,...). 
These are the names for the basic fields shown 
in Figure 1. 

Obviously, the bullet fields themselves 
couldn’t be smart directly; their purpose in life 
is just to store data. Each bullet field got a “super¬ 
visor” calculation field that implemented the 
concept of “smart bullets.” In designing the 
intelligence for the supervising fields, I decided 
that it should evaluate to either zero, indicating 
that the field should not be used, or that it 
should indicate its position in the list. Here is 
an example of how I implemented this logic for 
the fourth bullet: 

BulletFourSeq = {numeric result} 

If (BulletTextFour *"" and CheckFour =1 + 

If (BulletTextOne *"" and CheckOne =1,0) + 
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If (BulletTextTwo *"" and CheckTwo = 1,0) + 

If (BulletTextThree*""and 
CheckThree = 1,0), 0) 

In this calculation the first If statement 
checks to ensure that the bullet text is not blank 
and that the checkbox is not selected. If either 
of these tests fail, the sequencing field bails out 
of the If statement and returns a value of zero. 
If the nested multiple If statements are evaluat¬ 
ed, they perform similar checks on each of the 
preceding fields and each true If evaluation 
adds 1 to the running total. Note that the calcu¬ 
lation is performed more quickly if it is de¬ 
signed so that the additional If statements are 
not evaluated when the the first test fails. 

A similar supervising field is needed for 
each BulletText field. Note that each supervi¬ 
sor has a number of nested Ifs appropriate for 
its numeric position — BulletFiveSeq has five 
Ifs. When all the supervisors are in place we 
can then select and deselect checkboxes at will 
and the sequencing fields will report the proper 
orders for all the bullet fields. 

Before going on, however, let’s look at a 
way to improve this calculation. Though what 
we have works well, with a small change we can 
improve both speed and reliability and increase 
the likelihood that another FileMaker designer 
can figure out what we’ve done. The way to do 
this is to test the results from the preceding 
“smart bullets” instead of testing to see whether 
all previous checkbox and field pairs meet the 
usage criteria. So, instead of writing: 

If (BulletTextTwo ^"" and CheckTwo = 1,0) 

we’d write: 

If (Bullet2Sequence = 0,0,1) 

Here’s what the improved version of 
BulletFourSeq looks like: 

BulletFourSeq = {numeric result] 

If (BulletTextFour *"" and CheckFour = 1 + 

If (BulletOneSeq = 0,0,1) + 


If (BulletTwoSeq = 0,0,1) + 

If (BulletThreeSeq = 0,0,1), 0) 

This may not seem a lot different, but in 
my experience it has several benefits that make 
it better. It is slightly faster because one fewer 
test needs to be conducted for each of the nest¬ 
ed If statements. Because this algorithm refer¬ 
ences the other fields, it is easier to understand 
how this field decides its order in the list. Fields 
named with a description of what they do make 
it easier for other designers to figure them out. 
Ultimately, though, the most important reason 
to reference the results of the other sequencing 
fields is that it reduces redundant code in your 
database. Your database is much more main¬ 
tainable and less prone to breaking when each 
field only tests what it needs to test and relies 
upon other fields for the remainder of the data 
it needs. The differences maybe more clear in a 
visual diagram. 

Figures 4 and 5 illustrate how I see the two. 
The first is “messy” and the second seems more 
logical to me. The rippling interdependencies 
are much clearer to visualize and maintain. 
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Figure 5 Figure 4 






Now that we’ve finalized the sequencing 
fields, let’s take a look at how the smart left 
column field works. The key to this calculation 
is that the left column will only use the bullets 
that are odd numbers in the list of sentences to 
be used. In other words, out of ten possible 
sentences, the left column will use bullets one, 
three, five, seven and nine if they are all avail¬ 
able. The only trick here is to determine wheth¬ 
er a given field is in an even or odd list position. 

The solution lies in FileMaker’s (infre¬ 
quently used) Modulo function. The function 
is structured as Mod (number, divisor). Ac¬ 
cording to the FileMaker Pro manual “The 
Mod function returns a number that is the 
remainder after number is divided by divisor.” 
By using the sequencing field as the first argu¬ 
ment and 2 as the second argument, Mod will 
tell us whether the value in the sequencing field 
is even or odd. The only exception to this is if 
the sequencing number indicates that its corre¬ 
sponding bullet field is first in the list or is not 
to be used at all. Using the Mod function, we 
can evaluate all ten of the bullet sequencing 
fields and only concatenate those fields that 
occupy an odd position in the list. The only 
difference between the left and right “smart 
columns” is that one looks for even positions 
and the other for odd. 

An option included in the Column calcu¬ 
lation is whether to concatenate a symbol as a 
prefix for each line. User control of this option 
is through the Use Bullets field (Figure 1). 

Sym = If (Use Bullets = 1,"*","") 

Sym tests to see if the Use Bullets check¬ 
box is selected. If so then “• ” is output, other¬ 
wise it is equal to nothing (“”). The symbol 
used can be changed by modifying this equa¬ 
tion. The user thus controls the presence of the 
symbol character with each bullet sentence. 

The sample calculation for the smart left 
column shown below includes testing for just 
the first five sequencing fields in order to 


abbreviate the calculation fisting. 

Left Column = {text result} 

If (BulletOneSeq = 1, Sym & BulletTextOne 
& "IT,"") & 

If (BulletTwoSeq = 1, Sym & BulletTextTwo 
& "II","") & If (BulletThreeSeq < 1, 

If (BulletThreeSeq = 1, Sym & BulletTextThree 
& "D",If (Mod (BulletThreeSeq, 2) = 1, 

Sym & BulletTextThree & "IT,"")) 

& If (BulletFourSeq < 1, 

If (BulletFourSeq = 1, Sym & BulletTextFour 
& 'T,""), If (Mod (BulletFourSeq, 2) = 1, 

Sym & BulletTextFour & "11","")) 

& If (BulletFiveSeq < 1, 

If (BulletFiveSeq = 1, Sym & BulletTextFive 
&'T""),lf (Mod (BulletFiveSeq, 2) = 1, 

Sym & BulletTextFive & "II",'"')) &... 

The first sequencing field can only equal 
zero or one, so there is no need to perform any 
Mod operations. Similarly, the second sequenc¬ 
ing field can only be equal to zero, one or two, 
so even though we could use the Mod function 
here, there’s no need — if the field isn’t equal 
to zero or one its bullet field has to be occupy¬ 
ing an even position on the fist. Once we hit 
sequencing field number three, we finally see 
the complete formula for determining inclu¬ 
sion or exclusion that is repeated on each sub¬ 
sequent sequencing field. 

Like the “smart bullets” calculation field 
algorithm, this inclusion detector is designed 
to terminate as soon as it determines that a 
sequencing field contains either zero or indi¬ 
cates an even position on the fist. Initially it 
checks to see if the sequencing number is less- 
than-or-equal-to one. If this is true, then if the 
number is indeed I this indicates an odd posi¬ 
tion on the fist and we’ve met our search crite¬ 
ria. If the number isn’t 1 then of course we 
don’t use the bullet text at all. If the number is 
greater than one, we pass it to Mod. If Mod 
says that the remainder is equal to 1, then this 
tells us that the sequencing number’s bullet text 
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occupies an odd position and that it thus be¬ 
longs to this column. 

Conclusion 

In contrast to relational application gener- j 
ators, FileMaker is often considered to be less 
extendible; that if some set of functionality isn’t 
there, it can’t be added. However, with cleverly 
designed calculations, you can implement new 
features that significantly improve the utility of 1 

NameCode Update & For 

By Joe Kroeger 

Over the years the newsletter has on occasion 
visited the calculation of a NameCode for 
addresses. A NameCode is a field that tries to 
be unique for each record and is used for locat¬ 
ing and processing duplicate records. 

We use one here at the office that is orient¬ 
ed for address databases that have one record 
per person, for addresses dispersed across 
many ZIP codes, is derived from data within 
the record, and depends on specific treatment 
of last names and ZIPs elsewhere in the data¬ 
base. We take the first five characters from the 
last name (filling with hard spaces if necessary) 
and append the first five digits of the ZIP code. 

Our current version looks like this: 

NameCode = {text result} 

Upper (Left (If (Position (LastName," A ",1) = 0, 
LastName, Left (LastName, (Position 

(LastName," A ",1) -1))) &"-", 5)) 

& ZipTextFive 

The A character is used as a placeholder for 
a soft space (space bar) so if you copy the equa¬ 
tion be sure to substitute spaces for A . Similar¬ 
ly, the ~ character stands for a hard space 
(option-space bar). ZipTextFive is a calcula¬ 
tion that extracts the first five digits of the Zip- 
Text field. There are assumed to be no soft 


the database. With tools like this at your dis¬ 
posal, you can design sophisticated databases 
in a fraction of the time of a relational system 
and at a price that can’t be beat. 

Dave Burnett runs Quetzal Consulting, offering 
“complete FileMaker Pro design services. ” 
Phone San Francisco, CA, at 415-826-9496 
or internet at dburnett@netcom.com. 
Demo version of AutoSign is available 

Canada 

spaces within the last name — they have been 
either eliminated or replaced with hard spaces. 
There are soft spaces before last name suffixes 
like “Jr” and “III”. 

This NameCode treads a careful line be¬ 
tween being more specific, thus more nearly 
unique, and being more general to capture 
additional likely duplicates. It is used as stage 
one in a three layer assault on duplicates. 

This approach can be adapted for use with 
Canadian addresses as well. The same operat¬ 
ing context applies. We keep Canadian ad¬ 
dresses in a separate database so we have no 
worry about mixing NameCode styles. The 
U.S. ZipText field is replaced by the Canadian 
Postcode field. Canadian postcodes are consis¬ 
tently seven characters long (unlike the ones in 
England); three characters each at the begin¬ 
ning and end with a space in the middle. I 
wanted to remove the space from the middle 
and keep the remaining six characters: 

NameCodeCan= {text result} 

Upper (Left (If (Position (LastName," A ",1) = 0, 
LastName, Left (LastName, (Position 

(LastName," A ", 1) -1))) & "-", 5)) 

& Left (Postcode, 3) & Right (Postcode, 3) 

(Is there a Canadian subscriber who can 
suggest how to build a postcode table that 
would look up City and Province?) * 
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Quick Tips & Techniques j 

By Joe Kroeger 
Eratta 

Three corrections for the “I survived Win¬ 
dows” article in issue #57. On page 4 the phrase 
“EXPAND: 1 ” should be “EXPAND= 1 ” in¬ 
stead. In the section about cross-platform fonts, 
also on page 4, the phrase “Claris.ini” should 
instead be “Win.ini”. Thanks to Claris Win¬ 
dows Tech Support for catching these oopses. 

In addition, it seems we printed the wrong 
phone number for the author Douglas Brown. 

The proper number is 416-590-9081. Please try 
again if you didn’t get through before. 


The Lower Left Corner 

Down at the bottom left of our FileMaker 
windows are four buttons that we put to use 
once in a while. See Figure 1 below. 

The Browse button, when clicked, reveals 
navigation options that let you select Browse, 
Find, Layout, and Preview. I don’t use this 
button very often (the keyboard shortcuts 
work well for me) but sometimes it is nice. The 
button also serves to identify which type of 
screen is now active and in that role is quite 
valuable. 

The next button to the left toggles the tool 
palatte on and off and is quite handy. 

The next two buttons to the left enlarge or 
shrink the view in the window. Very nice for 
carving out tight layouts. 

The indicator that is next left shows the 
current magnification percent. But did you 

Figure 1 



iraaeoate itzoriz 
Trader 


know that it is also a button? If you click on the 
indicator it will take you back to 100% if you 
are at another percentage. Nice. As near as I 
can tell, this is a feature not documented in the 
FileMaker manual. 

File Similarity 

Do two files have same field name struc¬ 
ture? Instead of printing out both sets of field 
definitions and comparing them side-by-side, 
let FileMaker do a lot of the work. Just Import 
Records from one to the other, click the Match 
Fields button, and scroll through the resulting 
list of fields. Left-to-right arrows are present 
for non-calculation fields with matching names 
so they can be ignored. Calculation fields are 
grayed-out (since data cannot be imported 
into a calculation) and matching calculation 
field names are aligned. Non-matching fields— 
both calculation and non-calculation — will be 
aligned with whatever is next available in the 
list that is also unmatched. So the strategy is to 
look carefully at all entries that have no arrows. 
And remember to Cancel the Import when 
you are through! 

Stuffing Order 

(From Perri Sweet, Watertechnics) 

When printing a matching mailing set of 
both envelope labels and letters, it is nice to 
have the two end up in the same order so that 
stuffing the envelopes is more efficient. The 
physical sequence that your printer(s) handle 
both items will dictate whether reverse 
sequencing will help. You may want to Sort 
and Print the labels in ascending order and the 
letters in descending order, for example. (The 
“order” might be alphabetical by name or nu¬ 
merically by ZIP code.) When printing directly 
on envelopes, a printer often outputs in reverse 
order relative to output of letters. 
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